SAS is becoming more popular in enterprise storage systems. SAS may support SATA disk drives through a tunneling protocol (which may be referred to as SATA Tunneling Protocol (STP)). SATA was, however, not designed for a multi-device implementation. SATA is generally a point-to-point implementation. SATA is also limited because it is single duplex whereas SAS is a full duplex architecture.
Moreover, in operation, SAS may send input/output (I/O) data to SAS devices and is throttled by the target drive. For example, the initiator may send a task list to the target drive and the target drive may read or write data at its leisure. When SAS performs I/Os to SATA devices, a path between the initiator and the target is opened and held open for the length of the I/O. This is an inefficient use of the SAS bus, and holds off transactions to/from other targets.
In some current implementations, it is possible for a SATA device to operate in such a manner that its link will come up for a moment then be dropped. This causes a Serial Management Protocol (SMP) message to be sent through out the SAS domain, e.g., one for the link up then another for the link down. These messages inform the initiators on the domain that a change has taken place and that the initiators need to rescan the domain. The following rescan causes many more SMP messages or commands. This process may take a relatively long time and may consume valuable communication resources. If this process is continued in a SAS domain, little to no useful traffic propagation may be able to take place.
Accordingly, there is currently no good solution for the inefficiencies imposed by STP when SATA disk drives are coupled to SAS domains.